Is it OK to Re-publish an Event?
April 6th, 2009
Here’s a question that I can’t make up my mind on. So help me out…
For the sake of argument, lets agree that an event processing system/agent/application/engine works by; consuming events, performing some processing and eventually publishing an event as result.
With that in mind.
Is it generally allowed for the event processing system to (re) publish the same event it consumes?
For the question to make sense we also have to agree that any event processing system publishes an event when it wants to notify the outside world of an activity.
Suppose the event is an equivalent of an alarm state which would normally require an intervention — had to be fixed. For example, let’s think of a “low-level” indicator for a gas tank (red light situation). In this case it is would be OK to periodically “ping” an operator with a message. One may argue that it depends on the system that receives the event, so ultimately an optional setting for outbound events may resolve that dilemma.
If an event is a notification of the alarming situation, would not then publishing it twice mean that there are two alarms? Provided that we assume that events are published immediately as they happen as the whole point of CEP is to get notifications of things at once.
I think that an alarm (signal) would have to go off and on again to be considered ‘two alarms’. If an alarm recipient is an operator (SMS, email, tweet) it may be a good idea to remind him/her periodically. If a recipient is a program or a device which can track alarm state (on/off) it would simply ignore it. An equivalent would be sending message ‘turn light on’ to a light which is already on — ignored.
One of the beauty of events as opposed to plain data is that you can differentiate between seeing an alarm twice or seeing two similar alerts. If we have event agents which are supposed to work in real-time, then publishing an alert means that the alarm happens at the very moment it is published. This would make publishing the same alert by another component later on very weird and confusing.
Publishers are just publishers (maybe observers), but not creators of events. The publishing (and, as follows, reception) time must not have an impact on the event, and neither does its magnitude: a published event notification is just a representation of a view on that event. There may be different viewpoints, different notifications, all about the same event.
The event itself is unique by its temporal, spatial and contentual relation. This is the data that is (i.e. should be) used for the detection of correlation and for event composition. If the data is somehow distorted by the publisher’s view, auxiliary procedures have to make sure that the recipient – regardless of the view of the publisher – can infer the actual properties of the event. This way, the recipient can also detect that a repetitive publication is about one and the same event. I can imagine systems where the repetition (after some delay) of a publication might be desirable.
So, I think, in general, the answer to your question is yes.
However, in the real-time system you mentioned, when temporal relations are not checked on event (occurrence) attributes but inferred by the system’s supposed behaviour, repetitive publishing of an event must be illegal as it seems to introduce a new fact (a new inferred occurrence time) about the event.
It seems that we have at least two distinct models:
- One where event sources are publishing events of different kinds; Historical events, current events and perhaps even events from the future. Events can be published in any order and multiple times.
- Another option is that our event publishing agents are more structured and restricted. They could be seen as observers. Each agent observes something and is bound by the rules of engagement to publish a notification about the observation as quickly as possible. From the outside one could assume that when an agent publishes an event, something just happened at that very point in time and the event could be seen as a representation of that activity.
Is it possible to use SQL database to sort events?
@Vlatko
Sure, just create a suitable schema for the events and do your normal SQL routine. The trick is to achieve a suitably normalized schema so that you can actually use the power of SQL to manage your events. The same principles found in storing “normal” data apply, events are just a special case of data. Temporal aspects can be a bit tricky to manage with SQL though.
SQL is not good for sorting events. There is no write optimized SQL product on the market. Storing event data in Event Processing is a write problem.