Drools, as readers know, is pushing the boundaries of conservative (read “conservative” in the “bad” sense) software modeling and proving that there is a strong synergy between different declarative modeling technologies. More than that, a solution designer should have the freedom to chose the best metaphor for his model’s components, without worrying about the actual technology required to handle (read execute) such model.
That is why out of the box, Drools provides a platform that allows you to model processes, rules and to process events, using a single seamless and unified environment.
Although, such power and flexibility requires that users learn the different tools/features at their disposal, and preferably choose the best fit for the job.
A simplistic analogy is the classic: “give someone a hammer, and everything will look like a nail”. Stretch that scenario and imagine we also give him a screwdriver and he will have additional options:
- he can still continue to use only the hammer and results will continue the same, but still sub-optimal.
- he can start handling screws in a more efficient way with the screwdriver and we might imagine he will get better results
- or he can try to use the screwdriver for everything, including to handle plain old nails, and results might be worst than they were with the old and reliable hammer.
In the pure open source spirit we always try to help users and one of the more frequent confusions I face is, since the inception of Drools Fusion, when users start to see everything as an event. Like the third scenario above, that sometimes make things more difficult for them than they should.
The heart of the issue I would like to discuss is: what is an event?
There are several definitions for what an event is, but the one I like best is actually very simple:
“An event is a record of a significant change of state in a given point in time.”
What I always tell people when I am asked if something is an event or not, is to use this definition as a starting guideline to decide. There are 3 important aspects to it:
- An event is significant to the system: if your system deals with electronic air tickets sale, you probably will not care about a car accident in some random road, although the same event might be extremely important to a road traffic control system. Sounds obvious, but you would be surprised by how many users fall into this trap.
- An event represents a change of state: if you are monitoring a given sensor, lets say a power outage sensor, repeating events stating that power levels were ok at 2pm in the afternoon are probably useless after the first one was acknowledged. Please note that if the events inform about different points in time (like 2:05pm, 2:10pm, etc, they still represent changes of state from unknown to known state at that point in time).
- An event has an associated timestamp: there usually is no value in knowing that a building was on fire if I don’t know if that happened 100 years ago or if it is happening now, as sending fire workers there now for something that happened 100 years ago will probably be ineffective.
If your entity under analysis fails any of the above criteria, you can rule it out as an event. It might still be a fact though, as, from a Business Logic perspective:
“All events are facts, but not all facts are events”.
Using the 3rd example above, for an insurance system it might be worth to know that a building was on fire in the past, even if I don’t know when. In that case, that information would be a fact from my system, although not an event.
So, after knowing all that, I ask you the question:
Imagine an insurance claim processing system, is a claim an event?
And the answer is: “it depends!”
“WHAT?” you might ask. Yes, it depends. In the end, modeling something as an event or a regular fact are just tools at our disposal, and you might model a claim as an event or as a regular fact. It depends on what your system will do with such a claim. More often than not, there will be two entities in your model: a Claim fact representing the transactional (and mutable) data in your system, and a ClaimEvent, representing the actual claims coming into the system (remember you can’t change the past and so events should be treated as immutable instances). But I digress. Back to the point.
What do I do when **I** analyze a problem domain and have to decide on how to model an entity? Is it an event or a regular fact?
- I go over the above checklist. If the entity fails for any of those criteria, it is not an event.
- If it passes the criteria, I proceed to the practical aspects. Dealing with the temporal dimension is a complex matter that most users do not comprehend until they start dealing with it. There are only 2 features that can not be applied to regular facts: Sliding windows and automatic event life-cycle management (check the manual if you don’t know what they are). If I won’t need any of these features for the entity in question, I model it as a fact. I can always change my mind later and convert a fact into an event.
- If after the previous analysis I realize that I have an event in my hands, I will model it as an event and deal with it.
With that I am not saying that you should not use events. On the contrary, please use the best features for the job at hand. It is just that sometimes we allow ourselves to become too excited by the shiny new features that we forget that a hammer is still the best tool for the plain old nails.
PS: this post is intentionally directed to users with a Rules Engine background coming into the event processing world. One might realize in the future that users coming from the event processing world might use an analogous post regarding Rules Engines features.
Happy Drooling,
Edson
